monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] [RFC] move unversioned files out of the way


From: Zbigniew Zagórski
Subject: Re: [Monotone-devel] [RFC] move unversioned files out of the way
Date: Mon, 22 Sep 2008 10:10:35 +0200

2008/9/21 Thomas Keller <address@hidden>:
>
> Hi all!
>
> A annoyance for me has always been that monotone can't switch to another
> workspace if it has to remove directories which are not present in the
> target revision and these directories contain unversioned files (f.e.
> editor backup files). monotone then bails out with "X workspace
> conflicts" and lets the user clean up his mess.

Random idea related to topic: Maybe monotone could delete ignorable
files/folders? This would solve your problem in more pragmatic way -
no other options needed, just correct .mtn-ignore file.

Current behaviour is just strict implementation of "no data loss"
paradigm. Question is:

    Are ignorable files the same as "not important"?

If yes monotone can delete them.

I don't know the answer, for me it's almost yes. In my projects
ignorable files are always generated, backup or temporary. How is this
in other projects ?

Community must decide which behaviour is most expected.

> So I hacked something together last week or so, for which I want to get
> some feedback. The code resides in nvm.experiment.remove_leftover_files
> and essentially does the following:
> It introduces a new option --move-conflicting-paths for all
> workspace-update related commands (clone, checkout, update,
> merge_into_workspace) which then notices conflicting paths during the
> simulated working tree phase and moves these conflicting paths into
> _MTN/conflicts/DATETIME, where DATETIME is the current date/time stamp
> of the update operation.
> ...

If answer to above is no then it's the only reasonable solution.

BTW. This command is *reliable version of:

    mtn ls unknown | xargs mv --target-directory=$ROOT/_MTN/conflicts/$(date)

*reliable means - no name conflicts and no problems with whitespace in names.

Am I right?

Best regards,

-- 
Zbigniew Zagórski
/ software developer / geek / happy daddy /

reply via email to

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