monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Re: Cherry-Picking, Renames, Etc.


From: Oren Ben-Kiki
Subject: Re: [Monotone-devel] Re: Cherry-Picking, Renames, Etc.
Date: Mon, 29 Nov 2004 18:43:35 +0200
User-agent: KMail/1.7.1

On Monday 29 November 2004 14:43, Bruce Stephens wrote:
> Oren Ben-Kiki <address@hidden> writes:
>
> [...]
>
> >> > File renames are by far the most annoying part of having to deal
> >> > with a version control system.
> >>
> >> Is that in fact so annoying?
> >
> > Definitely. You can't do "monotone move" in a GUI - some people
> > actually do use GUIs to manage their directory trees... And if you
> > do a "big" reorganization of your code, having to report each
> > change by hand to the version control system gets old very fast.
> > And so on. Besides, it is like having to apply a choke when
> > starting a car on a cold day, it practically screams for
> > automation.
>
> If you wanted to move lots of files around, and used some kind of GUI
> to do it, then I guess it would be annoying.  But how often does that
> happen?  Maybe most of us are just too used to cvs, but I don't see
> much evidence that people do lots of renaming even when they can (for
> example, I looked at some of the patchsets from Linux once, to see
> how file renames were expressed, and I had to look at quite a few
> before I found a rename).
>
> Anyway, it seems fairly clear that this can be layered on to any
> version control system that supports renaming.  If you want to use
> file ids, then use them, and just before committing, rescan your tree
> and issue the appropriate "tla mv", "monotone rename" or whatever
> commands.  You can either store the manifest file (the thing mapping
> between stable file ids and filenames) or generate it after checking
> out.  Similarly, you can use other heuristics if you think they're
> appropriate for your project.  For convenience, you'd want a little
> scriptability in the version control tool, but that doesn't seem hard
> to add.
>
> That seems to me to be a better implementation for Arch, too.  Right
> now, if you want something equivalent to what every other version
> control system has (in Arch terms, explicit) you need to have a
> separate id file for every file and directory.  Nothing wrong with
> that as an option, but it seems unnecessarily clumsy.
>
>
> _______________________________________________
> Monotone-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/monotone-devel




reply via email to

[Prev in Thread] Current Thread [Next in Thread]